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TECHNICAL MEMORANDUM 


THE VEHICLE INTEGRATED PERFORMANCE ANALYSIS EXPERIENCE - 
RECONNECTING WITH TECHNICAL INTEGRATION 

1. INTRODUCTION 


Today’s NASA is facing significant challenges and changes— improving insight, safety, and tech- 
nical integration; cultural changes; and finding new ways of doing business. Early recognition and fore- 
sight into these changes initiated the Vehicle Integrated Performance Analysis (VIPA) team. The purpose 
of this team was to reconnect the individual engineering disciplines into a team capable of performing 
system-level technical assessments in support of future program decisions. This Technical Memoran- 
dum (TM) describes the VIPA experience and outlines its history. VIPA’s foundations are thoroughly 
reviewed and its relationship to systems engineering from the project to the engineering discipline level 
are detailed. Contributions of the VIPA process to the new NASA objectives are outlined. 


2. HISTORY 


Very early in the Space Launch Initiative (SLI) program, a small team of engineers was asked to 
propose a process for performing a system-level assessment of a launch vehicle. The request was aimed 
primarily at providing technical insight and making NASA a smart buyer of a second-generation launch 
architecture. Out of this effort, the VIPA team was created. During the first half of 2002, VIPA supported 
the SLI program with independent technical insight and participation in its technical reviews. The sec- 
ond half of 2002 brought a transition of the SLI program to the Orbital Space Plane (OSP) program. 
During this transition, the VIPA team was permitted to continue developing its capabilities for future 
support of the OSP program. VIPA also worked on validating processes and tools against realistic data 
from the Saturn V program. As the OSP program started, VIPA was asked to provide technical assess- 
ments of several OSP concepts launched on existing expendable launch vehicles (ELVs). VIPA was 
able to provide a substantial amount of objective system performance data enabling informed program 
decisions. Recently, after a brief hiatus, the VIPA team was reassembled to provide additional technical 
insight in support of the Space Exploration Initiative’s heavy-lift launch vehicle trade studies. Figure 1 
shows the history of VIPA. 
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Figure 1. VIPA history. 
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3. VEHICLE INTEGRATED PERFORMANCE ANALYSIS FOUNDATION 


During the initial formulation of the VIPA process, there was a strong desire to incorporate the 
lessons of the past. It was realized that the area of technical integration is where the majority of system 
problems are rooted. Just prior to the VIPA effort, a NASA Technical Publication (TP) 1 was written and 
published by several well-respected NASA engineering leaders. This TP captured many of the past les- 
sons in this area and became the basis of much of the VIPA process. 

Reference 1 was used as a point-of-departure and focal point for all discussions with the differ- 
ent technical disciplines during the VIPA process formulation. It describes how vehicles were designed 
and analyzed in the past. VIPA was established to exercise and improve the design and analysis process. 
Much of the framework of reference 1 was retained, however, the insights gained during this formula- 
tion enabled the involved disciplines to see their work in a different, more systemic way. 

The involved disciplines, via this more systemic view, were then able to focus more activities 
on system interactions, sensitivities, margins, and identification of technical risks. This further enabled 
them to define improved discipline processes that allowed for quick trade studies and identification of 
system impacts. The VIPA process now provides for more detailed and integrated analyses earlier in the 
design process, which enables better decisions. Two of the main conceptual models of reference 1 —the 
T-Model and the General Model— emerged as the most significant concepts enabling this systemic view 
and will be described in following sections. 
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4. SYSTEMS ENGINEERING AND TECHNICAL INTEGRATION 


The discussion of technical integration and systems engineering can get, by engineering stan- 
dards, emotional. This is primarily due to the broad definition of the subject and its diverse meaning to 
different groups of engineers and engineering management. Reference 2 defines systems engineering as 
“an interdisciplinary engineering management process that evolves and verifies an integrated, life-cycle 
balanced set of system solutions that satisfy customer needs.” Technical integration is defined by refer- 
ence 1 as: 

The interactive activity among all participants in the design process, whereby the compartmental- 
ized parts reintegrate into a balanced, successful total design. Technical integration is enabled by 
formal and informal information flow methods, by a system focus of all participants on how their 
part affects the total system, and by leadership that continually ensures that interactive aspects of 
design are being addressed and balanced. 

Both references acknowledge the very broad definitions of systems engineering and technical 
integration and that most engineers involved can claim to be performing some part of this process. If 
anything, the definition of technical integration is broader. However, both references allude to a further 
division of this process. Reference 1 refers explicitly to a “formal” and “informal” information flow, 
while reference 2 indicates that systems engineering is a management process, which implies formality. 
This difference between “formal” and “informal” is most likely at the crux of the difficulty for produc- 
tive discussions between engineering and engineering management. The T-Model for technical integra- 
tion is useful for exploring this difference. 

4.1 T- Model for Technical Integration 

Figure 2 shows the representation of the T-Model from reference 1. The model is divided into 
three distinct levels. All three levels are vital to the total integration, and all three will overlap. The 
vertical legs represent the discipline or component engineering functions that generally require a more 
intense, self-centered view to adequately design, analyze, and understand specific technical issues. It is 
recognized that these discipline functions should maintain awareness of the integrated system. However, 
it is still fair to say that the deeper one goes into a discipline or specialty the less system focus there is. 
Engineering disciplines have a long history of study and formalized education programs. There should 
be no need, and little benefit, in redefining terms in this area. 

The topmost half of the horizontal bar represents the formal aspects of technical integration. 
According to references 1 and 2, this level’s focus and responsibility is on the overall technical manage- 
ment and certification of the system. The project and project leader are the primary facilitators of this 
level. Reference 1 further states that the leader accomplishes goals with the support of “the tools and 
functions of the systems engineering discipline.” These functions are defined by reference 1 as “plan- 
ning, control, and documentation.” This reinforces the formal nature of this level and its primary con- 
cern with leading, monitoring, and controlling the total technical integration, i.e., all three levels. 
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T-Model for Technical Integration 
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Integration is Everyone’s Responsibility 


Figure 2. T-Model for technical integration. 


This formal system engineering, like discipline engineering, has been written about and studied 
extensively from the formal project management point-of-view of planning and control. The definition 
quoted from reference 2 above is a good definition. 

The middle level, or lowermost half of the horizontal bar, is the primary focus of the VIPA 
process. This level is characterized by the informal integration of the discipline and component func- 
tions. This is where the discipline and component efforts are brought together into a system analysis of 
the product to ensure that a viable, technically integrated product can be achieved. It is at this level that 
discipline/component discovered sensitivities and interactions are assessed together as a system. Also at 
this level, requirements are validated, performance is verified, and more importantly, derived require- 
ments are uncovered. 

Most discipline engineers consider this informal integration, or integrated systems analysis, as 
the essence of systems engineering, which conflicts with the more formal management definition. There 
should be a new term to define this level of integration in order to reduce confusion and allow more 
productive discussions. The term “informal” is inadequate considering the amount of effort that occurs 
in this integration and particularly since the VIPA effort has attempted to add “process” to this level. 

The following definition is proposed based in part on the reference 1 definition of informal integration: 

Analytical Integration— A communication and analysis activity that consists of interactions 
among discipline and design functions. The focus of this activity consists of data exchange, integration, 
and physics-based analysis to assess the behavior of the functions as an integrated system. This system 
behavior is influenced by physical attributes, interactions, sensitivities, and uncertainties brought for- 
ward by the discipline and design functions. 
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The VIPA process focuses on this level of informal integration because NASA’s capabilities in 
formal systems engineering and discipline expertise are already well established. The process encour- 
ages engineering disciplines to interact and focus less on discipline analysis and more on analytical inte- 
gration and system interactions. The depth of penetration into any discipline is driven by the sensitivities 
and uncertainties. 


4.2 General Model 

Reference 1 defines General Model as a “generalized description of the vehicle (system) that 
is evolved through synthesis/analysis activities directed toward overall vehicle (system) performance.” 
VIPA uses the development of this model as the catalyst to focus the disciplines on the system interac- 
tions rather than detailed discipline assessments. Each involved discipline is encouraged to develop dis- 
cipline-specific or specialized models that feed into this General Model for a system- wide analysis cycle 
(fig. 3). This effectively forces each discipline to determine its true drivers. It also forces the disciplines 
to stay consistent with the level of definition appropriate for the project phase. This allows the correct 
model fidelity to perform the necessary trade and sensitivity analyses required for that phase. Once these 
drivers are determined, they can then be assessed for system sensitivities and uncertainties. These inte- 
gration issues are the factors that will drive the system design and derive further system requirements. 



Figure 3. Relationship between VIPA models. 


VIPA work to date has been on launch vehicle systems. For this purpose, a guidance and trajec- 
tory simulation code was chosen as the backbone to the General Model. This is the most sensible choice 
for launch vehicles. For other applications the sensible choice may be something different. A habitat 
module system may dictate a mission operation timeline be chosen; a deep space probe may dictate 
an orbital mechanics simulation; or an in-space assembly may dictate a mockup and manufacturing 
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assembly simulation. While the choice of the backbone is important— it is not critical. The critical factor 
is that a backbone be chosen and used to focus the entire team on discipline interaction issues. VIPA has 
successfully brought forward the use of simplified indicator models that have been traditionally used in 
flight simulation. It has also appreciably progressed in incorporating additional detailed data recovery 
modules for aeroheating, structural loads, and stress. Having the objective of such a simulation provides 
the necessary integration focus to the team and needs further development. 
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5. PEOPLE, EXPERIENCE, CHALLENGE, PROCESS, AND TOOLS 


The General Model described is not an all-encompassing interdisciplinary software tool that 
instantaneously assesses any system. It is a collection of various tools and models constructed by each 
discipline for this current system at its current stage of evolution. The true insight into any system is 
gained in the effort of working as a team to construct this model. 

In fact, VIPA’s emphasis is on the people in the process as illustrated in figure 4. Experienced 
people faced with a challenge will develop a process and generate tools that enable that process. By 
involving new people, productivity can be increased while they gain experience with the tools. They 
can then be challenged and they will improve the process and the tools. It is truly the people that make 
a system work, and the VIPA process not only assesses the system but also develops the people along 
the way. 



Figure 4. VIPA is about people. 


In the past, all attempts to automate the process have focused on the tools, not the process or the 
people. VIPA was the first attempt to use the tools to focus the people, experience, and process. 
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6. SELECTED RESULTS 


The VIPA team has produced an overwhelming amount of data during its vehicle analysis cycles 
(VACs). The integration process demands that these data be generated and shared. The data generated 
during the Saturn V exercise were particularly interesting. It was during this process that many of VIPA’s 
processes and tools were validated against actual flight data. It was also during this cycle that the VIPA 
team members started to understand the integration process and formed strong commitments to that 
process. Figure 5 shows a very brief summary of data created during the Saturn V cycle. Note that the 
vehicles and hardware depicted are CAD representations down to the skin and stringer level. During this 
short 3-mo cycle, tools were developed and improved, flight reconstructions were created, and trades 
were conducted using advanced materials and engine concepts. 
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Figure 5. Saturn V exercise: sample results. 
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7. SUPPORTING THE NEW NASA 


Today’s NASA is facing significant challenges and changes. The Space Exploration Initiative 
indicates a large increase in projects with limited increase in budget. The Columbia report has criti- 
cized NASA for its lack of insight and technical integration impacting its ability to provide safety. 3 
The Aldridge report is advocating NASA find new ways of doing business. 4 In addition, experience 
with several programs from X-33 to OSP has indicated that NASA engineering had a difficult time 
transitioning from Phase C/D detailed work to more preliminary Phase A/B and insight work. 

The bottom line to all these changes is that NASA must become a smart buyer. This implies that 
NASA must efficiently do its homework to correctly define its requirements, select viable providers, and 
ensure adequate performance without stifling creativity and innovation. It is likely no longer cost effec- 
tive for NASA to get into the very detailed Phase C/D work. Contractors can do this more efficiently. 
However, NASA cannot afford to walk blindly into a review and grade a contractor based solely on a 
PowerPoint® presentation. NASA also cannot afford to quickly review a requirements document to see 
if it has the correct design criteria for a system that is substantially different from anything in its experi- 
ence. In order to have the correct level of insight into both the requirements and the performance, NASA 
must leam to work efficiently within the middle level of the T-Model. 
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8. V-MODEL 


The process that VIPA uses to assess both performance and requirements is very similar to the 
compartmentalization, design, and reintegration functions discussed in reference 1. VIPA refers to this 
as the V-Model, and it is illustrated in figure 6. As can be seen at the center of the V, this process is 
driven by the general, discipline-specific, and specialized models. 



Specialized Models 


Documented 


' Start 
Analysis 
Cycle 


General Model 


Discipline-Specific Models 


Capability 


Verify Stated 
Performance 


Reintegration 


Feed System Residual Weight Issues 

• Booster Oxidizer Lines =52,400 Ibm 

• Booster Kerosene Lines =1 ,970 Ibm 

• Orbiter Oxidizer Lines =9,400 Ibm 

• Orbiter Hydrogen Lines =70 Ibm 

Validate Input Data 


Figure 6. VIPA V-Model. 


The first leg of this process is to verify stated performance. This is the stated performance of 
a candidate or generic concept for a given set of requirements. This verification process is achieved 
by reviewing the given concept and generating the integrated General Model that will predict its perfor- 
mance. It is during this process that insight is gained into the concept by doing, rather than reviewing. 
Upon completion of this leg, the stated performance of the concept can be verified by using provided 
inputs in the General Model to match reported results. 

Once this leg is complete, the given inputs for the concept can be validated. This is accomplished 
by each of the involved disciplines using insight gained in formulating the general and discipline-specific 
models, along with experience. These models can then be used to determine sensitivities, performance 
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partials, and uncover issues related to the concept or being driven by requirements. This is a study period 
at the bottom of the V. 

Finally, any sensitivities or issues that were identified can then be reintegrated along the final 
leg. This is done using the General Model to determine integrated system impacts to performance result- 
ing from altered inputs or requirements. 

An example of how this process can be used during the initial development of a project is as fol- 
lows. The VIPA team would be assembled and begin work at the same time as potential contractors, just 
after the systems requirements drop occurring in the upper left corner of the V. The VIPA team would 
work in parallel with the contractors generating their own models of possible concepts while keeping 
abreast of the contractors’ progress and concepts via the project offices. 

The bottom of the V occurs just prior to and during the systems requirements review. During this 
period, the contractors’ inputs and results are validated and issues are identified. Using the insight gained 
during the first leg significantly improves this review process. 

Finally, the reintegration efforts occur, incorporating further contractor inputs, models, and sensi- 
tivities in performance predictions. This effort could result in requirement changes, contractor selections, 
or redirections. The process would then repeat itself on its way to the next review cycle. 

By incorporating the VIPA process during this development cycle, NASA is effectively doing its 
homework and becoming a smart buyer— able to make informed decisions. This process adds real value 
over and above the value of discipline experts providing commentary concerning concepts to which they 
were only recently exposed. By using the VIPA process, NASA’s effort is more efficiently allocated to 
assessing significant system drivers. This is the process VIPA used during initial SLI and OSP cycles. 
The VIPA work added significantly to the reviews and was well received by both engineering and proj- 
ect organizations. 
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9. CONCLUSION 


A brief summary of the VIPA experience has been presented. VIPA is a new way of applying 
existing people, skills, and tools to complex problems. VIPA’s processes are grounded in traditional 
engineering capabilities and have been exercised and validated. VIPA concentrates on system-level 
interactions, sensitivities, and margins to identify technical risks. VIPA is able to bring more detailed 
and integrated analyses earlier into the design process by enhancing the traditional capabilities with 
improved analysis technology thus allowing more informed program decisions. Finally, VIPA is a 
people-centered process that fosters continued growth of experience, processes, and tools through 
challenging productive work. VIPA’s work has been applauded by both engineering and project 
management organizations. 
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